با توجه به اینکه دیدم خیلی از دوستان در این مورد سوال دارند دلم نیومد این مقاله ارزشمند رو اینجا نزارم :

در معماری چند لایه تمام برنامه به چندین بخش تقسیم می‌شود. این بخش‌ها می‌توانند فیزیکی یا منطقی باشند. هر بخش کار خاصی را انجام می‌دهد مثلا نمایش interface کاربر یا دسترسی به داد‌ه‌ها. برنامه می‌تواند به هر تعداد لایه داشته باشد ولی به هر حال بیش‌تر برنامه‌ها سه لایه‌ی مجزا دارند که عبارت‌اند از:



همان‌طور که احتمالا حدس زده‌اید، لایه‌ی Presentation چیزی نیست به جز بخشی از نرم‌افزار که با کاربر برنامه‌ی شما ارتباط برقرار می‌کند (interface برنامه‌ی شماست). نمایش داده‌ها به کاربر نهایی و اجازه به آنان برای ارتباط داشتن با داده‌ها، اصلی‌ترین وظیفه‌ی این لایه است.

در بیش‌تر موارد، داده‌هایی که توسط کاربر وارد می‌شوند نیاز به اعتبارسنجی یا پردازش اضافی دارند. این مسؤولیت لایه‌ی Business Logic است.

در نهایت داده‌های برنامه‌ی شما نیاز به ذخیره و بازیابی از طریق یک انبار داده دارند (مثلا سیستم مدیریت DataBaseهای رابطه‌ای یا RDBMS و یا XML و ...) این وظیفه توسط لایه‌ی دسترسی به داده انجام می‌شود.

به‌طور خلاصه، فرایند مورد نظر ما این‌گونه کار می‌کند:

- کاربر برای داده‌های برنامه، درخواستی ارسال می‌کند.

- لایه‌ی Data Access داده‌های مورد نظر را بازیابی می‌کند و از طریق لایه‌ی Business Logic آن‌ها را به لایه‌ی نمایش می‌فرستد. بعضی مواقع لایه‌ی دسترسی به داده‌ها، این داده‌ها را مستقیما به لایه‌ی نمایش ارسال می‌کند.

- لایه‌ی نمایش اطلاعاتی که باید نمایش داده شوند را از طریق لایه‌ی Business Logic دریافت می‌کند.

- کاربر داده‌ها را تغییر می‌دهد و عمل مناسب در مورد آن‌ها را اجرا می‌کند (مثل اضافه یا به‌روز کردن داده‌ها)

- لایه‌ی Business Logic صحت داده‌های وارد شده توسط کاربر را بررسی می‌کند (داده‌ها را اعتبارسنجی می‌کند)

- اگر داده‌ها معتبر باشند آن‌ها را برای به‌روز رسانی در بانک اطلاعاتی به‌دست لایه‌ی دسترسی به داده می‌سپارد.



مزیت‌های برنامه‌های چند لایه

- برنامه‌ها به چند بخش منطقی جدا از هم تقسیم می‌شوند و اتصال میان UI (رابط کاربری)، پردازش‌ها و بانک اطلاعاتی کم می‌شود.

- تغییر در بانک اطلاعاتی یا روال‌های دسترسی به داده‌ها، تاثیری در لایه‌ی نمایش یا برنامه‌ی کلاینت نخواهد گذاشت.

- برنامه‌ی کلاینت با عبارات SQL آمیخته نخواهد شد.

- نام جداول و ستون‌ها به‌طور مؤثری از برنامه‌ی Client حذف می‌شوند.

- برنامه‌ی Client نمی‌فهمد که داده‌ها از کجا آمده‌اند (چیزی که به آن Location Transparency گفته می‌شود)

- تغییر یا گسترش برنامه بسیار ساده‌تر خواهد شد، بدون نیاز به تغییر یا کامپایل مجدد برنامه‌ی Client.

نکته‌ی منفی در معماری چند لایه این است که شما باید تعداد زیادی بخش‌ها و کلاس‌های ازهم جدا در نرم‌افزار بسازید. اما به هر حال مزایای این روش بیش‌تر و برتر از معایب آن است.



انتخاب‌های لایه‌ی Presentation

دو انتخاب اصلی برای ساخت یک لایه‌ی نمایش در دات نت وجود دارد. آن‌ها فرم‌های ویندوزی یا فرم‌های وبی ASP.NET هستند.

با استفاده از ویندوز فرم‌ها شما می‌توانید برنامه‌های دسکتاپ فرم محور (Form Base) معمول را بسازید. برنامه‌های ویندوز فرمی می‌توانند المان‌های رابط کاربری بسیار غنی به‌کاربر پیشنهاد کنند. آن‌ها کم و بیش شبیه به فرم‌های ویژوال بیسیک هستند.

جذاب‌ترین گزینه برای توسعه‌ی لایه‌ی نمایش استفاده از وب فرم‌های ASP.NET است. کنترل‌هایی مثل: دیتاگرید، دیتالیست و تقویم (Calendar) یک رابط کاربری قدرتمند را با مقدار کمی کد فراهم می‌کنند.

انتخاب‌هایی که در بالا برای ساخت یک لایه‌ی نمایش بررسی کردیم می‌توانند توسط زبان‌های مختلفی مثل C#Visual Studio.Net پیاده‌سازی شوند.


انتخاب‌های لایه‌ی Business Logic

لایه‌ی Business Logic از چندین بخش که کارهایی نظیر اعتبار سنجی کار، گردش کار یا کارهای مشابه را انجام می‌دهند تشکیل شده است.

Componentهای .Net این لایه را شکل می‌دهند. شما می‌توانید با Interop از Componentهای COM استفاده کنید ولی این کار کارایی را پایین خواهد آورد.

وب‌سرویس‌های ASP.NET هم می‌توانند به‌عنوان یک Business Logic عمل کنند. اما به هر حال آن‌ها را نمی‌توان در همه‌ی شرایط به‌عنوان جایگزین Componentها به‌کار برد. وب‌سرویس‌ها تنها زمانی قابل استفاده خواهند بود که اعتبارسنجی در جایی بیرون از شبکه‌ی شما اتفاق افتاده باشد.

Componentهایی که توسعه می‌دهید به ماندن روی ماشین‌های مشابه نیازی ندارند. با استفاده از دات NET Remoting می‌توانید آن‌ها را روی چندین ماشین توزیع کنید.


انتخاب‌های لایه‌ی Data Access

این لایه با دستکاری داده‌ها مثل اضافه، حذف و به‌روز رسانی آن‌ها سر و کار دارد. داده‌هایی که به آن‌ها اشاره کردیم می‌توانند در RDBMS یا XML قرار داشته باشند. شما باید لایه‌ی دسترسی به داده را چنان طراحی کنید که دیگر لایه‌ها نیازی به دانستن وضعیت انبار داده‌ها نداشته باشند.

ADO.NET فناوری دسترسی به داده‌ی تحت دات .Net است. اگر چه ADO.NET از طریق کلاس‌های DataReader اجازه‌ی دسترسی به داده‌های در هنگام اتصال را می‌دهد ولی بیش‌ترین تمرکز روی دسترسی به داده‌ها در زمان متصل نبودن است. DataSet نقش کلیدی را در این مورد بازی می‌کند. در بعضی موارد می‌توانید ADO را هم برای دسترسی به داده‌ها استفاده کنید ولی استفاده از آن باید دلیل معتبری داشته باشد. از ADO استفاده نکنید فقط به خاطر این‌که RecordSetها را دوست دارید!

این‌جا هم Componentهای .Net لایه را تشکیل می‌دهند. همان‌طور که قبلا گفته شد می‌توانید از Componentهای کلاسیک COM هم استفاده کنید.

هم‌چنین وب‌سرویس‌ها هم می‌توانند لایه‌ی دسترسی به داده را شکل دهند. این مخصوصا زمانی درست است که DataBase شما فراهم‌کننده‌ی (Provider) داده ندارد. در این‌گونه موارد شما می‌توانید مقداری کد برای اتصال به داده‌ها و پر کردن DataBaseها و بازگرداندن نتایج درون DataSet به درخواست‌کننده‌ی داده بنویسید.

علاوه بر ADO.NET شما می‌توانید از امکانات سیستم مدیریت DataBase خود مثل توابع و یا روال‌های ذخیره شده (Stored Procedures) استفاده کنید.


ارسال داده از یک لایه به لایه‌ی دیگر

در تمام موارد به ارسال اطلاعات از یک لایه به لایه‌ی دیگر نیاز است؛ به‌طور معمول برنامه‌نویسان از رشته‌ها، آرایه‌ها، RecordSetهای غیرمتصل برای رسیدن به این هدف استفاده می‌کنند. در .Net ، DataSetها یک راه فوق‌العاده برای انتقال اطلاعات میان لایه‌ها فراهم می‌کنند. شما حتی می‌توانید با برنامه‌نویسی یک DataSet بسازید و آن را با داده‌های خودتان پر کنید. اگر اشیا را خیلی دوست دارید می‌توانید از Typed DataSets استفاده کنید که در واقع کلاسی مشتق شده از کلاس DataSet است که جداول و سطرها را به شکل یک شی معرفی می‌کند.


منبع :رشد

نجف زاده ::: پنج شنبه 87/6/7::: ساعت 10:11 عصر

نجف زاده
برای دستیابی به پروژه ها و پایان نامه های دانشجویی به آدرس www.bitasoft.ir مراجعه فرمائید.